Jag är inte säker på hur jag verkligen kan formulera min fråga så låt mig försöka förklara den med ett exempel: Låt oss säga att mitt program stöter på något konstigt beteende vid en specifik åtgärd. Jag hittar redan en kod som är orsaken till detta konstiga beteende. När jag inaktiverar denna sekvens stöter jag inte på detta beteende. Tyvärr behöver jag den här koden eftersom något annat inte fungerar då. Så vad jag ska göra härnäst är att ta reda på varför något går annorlunda när det kodutdraget är aktivt. För att bättre förstå vad som händer vill jag ibland köra hela åtgärden inklusive "dålig kod" och ibland utan. Sedan kan jag jämföra resultatet, till exempel vad som händer i användargränssnittet eller vad min funktion returnerar. Det första tillvägagångssättet som jag tänker på är att köra mitt program med kod aktiverad, göra vad jag vill, sedan stoppa mitt program, kommentera koden, kompilera om och köra igen. Um ... det låter dumt. Speciellt om jag sedan igen måste slå på den koden för att se en annan gång det andra beteendet, och sedan igen stänga av, på och av och så vidare. Det är inte ett alternativ för mig att använda brytpunkter och påverka uttalande ordningen eller att ändra värden så att jag stöter på eller inte stöter på if-uttalanden, för-loopar etc. Två exempel: Jag felsöker ett tidskritiskt beteende och när jag stoppar programmet ändras tidpunkten avsevärt. Således måste den första brytpunkten som jag kan ställa vara i slutet av åtgärden. 1 Jag förväntar mig att en verktygstips eller ett annat fönster visas som är "undertryckt" när fokus ges till VS. Således kan jag inte använda några brytpunkter alls. Varken i början eller i slutet av åtgärden.1 Finns det någon teknik i Visual Studio 2012 som gör att jag kan markera den här koden som valfri och jag kan bestämma om jag vill köra den här kodsekvensen innan jag utför åtgärden? Jag tänker på något som om (true | false) på en högre nivå. Jag letar inte efter en lösning där jag behöver köra om mitt program flera gånger. I så fall kunde jag fortfarande göra det enkla tillvägagångssättet att helt enkelt kommentera koden med #if false. 1 Observera att jag naturligtvis kan ställa in en brytpunkt när jag behöver titta på en specifik variabel vid en viss position (om jag inte har skrivit värdet till utdata) men kommer att stänga av brytpunkter igen för att köra hela åtgärden i en gå.
2020-12-07 23:10:18
I Visual Studio-felsökaren kan du ställa in en brytpunkt precis framför din "kod i fråga". När koden stannar vid den punkten kan du välja att låta den fortsätta eller högerklicka på vilken annan rad som helst och välja Ange nästa uttalande.
Det är ett konstigt alternativ, men jag har uppskattat det.
|
Det enda alternativet jag kan tänka mig är att lägga till något i ditt användargränssnitt som bara visas vid felsökning, vilket ger dig möjlighet att inkludera / exkludera de aktuella operationerna.
Medan du håller på med det kanske du vill aktivera återställning av applikationen till ett "känt tillstånd" från gränssnittet.
|
Jag tänker på något som om (true | false) på en högre nivå.
Varför "på högre nivå"? Varför inte använda exakt detta?
Du vill att en kod ibland körs, ibland inte, och omkopplaren ska ändras vid körningstid, inte vid kompileringstid - detta leder uppenbarligen till
om (villkor)
{
// kod i spel
}
Fångsten här är vilken typ av villkor du kommer att använda - kanske en variabel som du ställer in till true i utgivningsversionen av din kod och till falsk ibland i din felsökningsversion. Kanske hämtas värdet från en konfigurationsfil, kanske från en miljövariabel, kanske beräknas av någon form av logik i ditt program, oavsett och när du vill.
EDIT: du kan också införa en boolesk variabel i din kod för villkor, initialisera den till true som standard och ändra dess värde med hjälp av felsökaren när du vill.
|
Förprocessordirektiven kan vara det du är ute efter. De är bitar av kod för kompilatorn att köra, identifierbara genom att börja med ett # tecken (och stilistiskt följer de som standard inte kodens streckmönster, utan bor alltid stadigt vid redigerarens vänstra kant ):
#define INCLUDE_DODGY_CODE
offentligt ogiltigt MyMethodWithDodgyBits () {
# om INCLUDE_DODGY_CODE
myDodgyMethod ();
#endif
myOkMethod ();
}
I det här fallet, om #define INCLUDE_DODGY_CODE inkluderades, samlas myDodgyMethod () -samtalet i ditt program. Annars hoppas samtalet över av kompilatorn och kommer helt enkelt inte att finnas i din binära version.
|
Det finns ett par alternativ för felsökning som du ber.
Visual Studio har ett antal alternativ för att navigera direkt genom koden. Du kan använda funktionen Set Next Statement för att flytta direkt till ett visst uttalande. Du kan också redigera värden direkt i snabbfönstret QuickWatch och verktygstips som svävar över variabler under felsökning.
Visual Studio har också möjlighet att spela upp körningshistoriken. Ta en titt på IntelliTrace för att komma igång. Det kan vara till hjälp när du har flera problemområden som interagerar och genererar felförhållandet.
Du kan också slå dina kodavsnitt i villkorliga block och ställa in de villkorliga variablerna efter behov. Det kan vara medan du felsöker, eller så kan du skicka parametrar genom en konfigurationsfil. Att använda villkorliga kontroller kan vara enklare än att manuellt gå igenom koden om det finns ett antal uttalanden du vill utesluta.
|
Ibland beror det på versionen av VS och språket, men du kan gärna redigera koden (för att kommentera den eller lägga den i en stor #ifdef 0) och sedan trycka på alt + F10 och kompilatorn kompilerar om, länkar om och fortsätter körningen som om du aldrig hade lurat med det.
Men även om det fungerar vackert i VC ++ (sedan VS v6 IIRC), kan C # ha problem - jag hittar (med VS2010) att jag inte kan redigera och fortsätta på detta sätt med funktioner som innehåller några lambda (främst linq) uttalanden och 64-bitars kod brukade aldrig göra det här också. Ändå är det värt att experimentera med det är riktigt användbart ibland.
|
Jag har arbetat med applikationer som har valfri kod som används för felsökning enbart som inte ska visas i produktionsmiljön. Det här segmentet av valfri kod var enklast för oss att kontrollera med en konfigurationsfil eftersom det inte krävde en omkompilering för att ändra.
En sådan lösning kanske inte är slutet för allt ditt slutresultat, men det kan hjälpa dig att komma igenom det tills en fix hittas. Om du har flera valfria avsnitt som måste testas i kombination kan den här fixningsstilen kräva flera nycklar i konfigurationsfilen, vilket kan vara en nackdel och en smärta att hålla reda på.
|
Din fråga är inte exakt klar, vilket är möjligen varför det finns så många svar som du tycker är ogiltiga. Du kanske vill överväga att omformulera den om ingen verkar kunna svara på frågan.
Med risken att ge ett annat ogiltigt svar kommer jag att lägga till lite information om hur jag har hanterat problemet tidigare.
Det enklaste sättet är att placera valfri kod i
# om DEBUG
// Valfri kod här
#endif
På det sättet, när du kör i felsökningsläge implementeras koden och när du kör i släppläge är det inte. För att växla mellan de två måste du klicka på en knapp.
Jag har också löst samma problem på ett liknande sätt med en enkel flagga:
bool runOptionalCode = false;
sedan
if (runOptionalCode)
{
// Placera valfri kod här
}
Igen,växling mellan lägen kräver att ett ord ändras, så det är en enkel uppgift. Du nämner detta i din fråga men diskonterar det av skäl som är oklara. Som sagt, det kräver väldigt lite ansträngning att växla mellan de två.
Om du behöver göra ändringar mellan koden medan den körs är det bästa sättet att använda ett UI-objekt eller en tangenttryckning som ändrar flaggan som nämns i exemplet ovan. Beroende på din ansökan kan detta dock vara mer ansträngande än det är värt. Tidigare har jag upptäckt att när jag har en nyckellyssnare redan implementerad som en del av projektet, har ett par tangenttryckningar bestämt om jag vill köra min felsökningskod (valfri). I en applikation utan viktiga lyssnare vill jag hellre hålla mig till en av de tidigare metoderna.
|
Ditt svar
StackExchange.ifUsing ("redaktör", funktion () {
StackExchange.using ("externalEditor", funktion () {
StackExchange.using ("snippets", function () {
StackExchange.snippets.init ();
});
});
}, "kodutdrag");
StackExchange.ready (funktion () {
var channelOptions = {
taggar: "" .split (""),
id: "1"
};
initTagRenderer ("". split (""), "" .split (""), channelOptions);
StackExchange.using ("externalEditor", funktion () {
// Måste aktivera redaktören efter utdrag, om utdrag är aktiverade
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using ("snippets", function () {
createEditor ();
});
}
annat {
createEditor ();
}
});
funktion createEditor () {
StackExchange.prepareEditor ({
useStacksEditor: false,
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: sant,
showLowRepImageUploadWarning: true,
reputToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Drivs av \ u003ca href = \" https: //imgur.com/ \ "\ u003e \ u003csvg class = \" svg-icon \ "width = \" 50 \ "height = \" 18 \ "viewBox = \ "0 0 50 18 \" fill = \ "none \" xmlns = \ "http: //www.w3.org/2000/svg \" \ u003e \ u003cpath d = \ "M46.1709 9.17788C46.1709 8.26454 46.2665 7.94324 47.1084 7.58816C47.4091 7.46349 47.7169 7.36433 48.0099 7.26993C48.9099 6.97997 49.672 6.73443 49.672 5.93063C49.672 5.22043 48.9832 4.61182 48.1414 4.61182C47.4335 4.61182 46.72543 4.916.56 43.1481 6.59048V11.9512C43.1481 13.2535 43.6264 13.8962 44.6595 13.8962C45.6924 13.8962 46.1709 13.2535 46.1709 11.9512V9.17788Z \ "/ \ u003e \ u003cpath d = \" M32.492 10.1419C414.042.42 12.6 12.6 41.5985 12.6954 41.5985 10.1419V6.59049C41.5985 5.28821 41.1394 4.66232 40.1061 4.66232C39.0732 4.66232 38.5948 5.28821 38.5948 6.59049V9.60062C38.5948 10.8521 38.2696 11.5455 37.0451 11.445.5 521 35.4954 9.60062V6.59049C35.4954 5.28821 35.0173 4.66232 34.0034 4.66232C32.9703 4.66232 32.492 5.28821 32.492 6.59049V10.1419Z \ "/ \ u003e \ u003cpath fill-rule = \" evenodd \ "clip-rule = \" evenod = \ "M25.6622 17.6335C27.8049 17.6335 29.3739 16.9402 30.2537 15.6379C30.8468 14.7755 30.9615 13.5579 30.9615 11.9512V6.59049C30.9615 5.28821 30.4833 4.66231 29.4502 4.66231C28.9913.561.4623.46 .1369 4.56087 21.0134 6.57349 21.0134 9.27932C21.0134 11.9852 23.003 13.913 25.3754 13.913C26.5612 13.913 27.4607 13.4902 28.1109 12.6616C28.1109 12.7229 28.1161 12.7799 28.121 12.8346C28.125 12.222 15.2321 24.1352 14.9821 23.5661 14.7787C23.176 14.6393 22.8472 14.5218 22.5437 14.5218C21.7977 14.5218 21.2429 15.0123 21.2429 15.6887C21.2429 16.7375 22.9072 17.6335 25.6622 17.63351724.124 27.2119 7.09766 28.0918 7.94324 28.0918 9.27932C28.0918 10.6321 27.2311 11.5116 26.1024 11.5116C24.9737 11.5116 24.1317 10.6491 24.1317 9.27932Z \ "/ \ u003e \ u003cpath d = \" M16.8045 11.9512C6.280.16 19.8079 13.2535 19.8079 11.9512V8.12928C19.8079 5.82936 18.4879 4.62866 16.4027 4.62866C15.1594 4.62866 14.279 4.98375 13.3609 5.88013C12.653 5.05154 11.6581 4.62866 10.3573 4.62866C9.34336 4.62866 8.59806 4.899 5.00066 5.28821 5.00066 6.59049V11.9512C5.00066 13.2535 5.47873 13.8962 6.51203 13.8962C7.54479 13.8962 8.0232 13.2535 8.0232 11.9512V8.90741C8.0232 7.58817 8.44431 6.91179 9.53458 6.91179C11.510 610.810 C13.4375 13.8962 13.9157 13.2535 13.9157 11.9512V8.90741C13.9157 7.58817 14.3365 6.91179 15.4269 6.91179C16.4027 6.91179 16.8045 7.58817 16.8045 8.94108V11.9512Z \ "/ \ u003e \ u003cpath d = \ "M3.31675 6.59049C3.31675 5.28821 2.83866 4.66232 1.82471 4.66232C0.791758 4.66232 0.313354 5.28821 0.313354 6.59049V11.9512C0.313354 13.2535 0.791758 13.8962 1.82471 13.89622.813.2535 3.31675 11.9512V6.59049Z \ "/ \ u003e \ u003cpath d = \" M1.87209 0.400291C0.843612 0.400291 0 1.1159 0 1.98861C0 2.87869 0.822846 3.57676 1.87209 3.57676C2.90056 3.57676 3.7234 2.9626 0.400291Z \ "fill = \" # 1BB76E \ "/ \ u003e \ u003c / svg \ u003e \ u003c / a \ u003e",
contentPolicyHtml: "Användarbidrag licensierade under \ u003ca href = \" https: //stackoverflow.com/help/licensing \ "\ u003ecc by-sa \ u003c / a \ u003e \ u003ca href = \" https://stackoverflow.com / legal / content-policy \ "\ u003e (content policy) \ u003c / a \ u003e",
allowUrls: sant
},
onDemand: sant,
discardSelector: ".discard-answer"
, immediatelyShowMarkdownHelp: true, enableSnippets: true
});
}
});
Tack för att du bidrog med ett svar till Stack Overflow!
Var noga med att svara på frågan. Ge detaljer och dela din forskning!
Men undvik ...
Be om hjälp, förtydligande eller svara på andra svar.
Att göra uttalanden baserade på åsikt; säkerhetskopiera dem med referenser eller personlig erfarenhet.
För att lära dig mer, se våra tips för att skriva bra svar.
Utkast sparat
Utkast kasseras
Registrera dig eller logga in
StackExchange.ready (funktion () {
StackExchange.helpers.onClickDraftSave ('# login-link');
});
Registrera dig med Google
Registrera dig med Facebook
Registrera dig med e-post och lösenord
Skicka in
Lägg upp som gäst
namn
E-post
Obligatoriskt men aldrig visat
StackExchange.ready (
funktion () {
StackExchange.openid.initPostLogin ('. New-post-login', 'https% 3a% 2f% 2fstackoverflow.com% 2fquestions% 2f19425104% 2fcan-i-mark-some-code-as-optional-while-debugging-in- visual-studio-2012% 23new-answer ',' question_page ');
}
);
Lägg upp som gäst
namn
E-post
Obligatoriskt men aldrig visat
Lägg upp ditt svar
Kassera
Genom att klicka på “Lägg upp ditt svar” godkänner du våra användarvillkor, sekretesspolicy och cookiepolicy
Inte svaret du letar efter? Bläddra bland andra frågor taggade felsökning visual-studio eller ställ din egen fråga.